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Response Time in Cross-network Debugging 


Cross-network debugging is a means whereby a programmer at one 
computer on a network can debug a program which executes on another 
computer. One form of cross-net debugging has been in use for some 
years by programmers who maintain IMPs on the ARPA network. Another 
form has been used by ARPA network users who employ TELNET or RSEXEC 
to log into a distant computer and remotely run a debugger on that 
machine. In both of these cases, the debugger is almost entirely 
resident in the same machine as the subject program, and only a 
remote means of access to that computer distinguishes the activity 
from single-computer debugging. 


In our case, we use a PDP-10 to perform complex debugging 
manipulations. Simple manipulations, and complex actions which the 
PDP-10 has partially digested into simple actions, are sent over the 
ARPA network to a PDP-11. The portion of the debugger resident in 
the PDP-11, where the subject program executes, can perform only 
simple actions (examine, deposit, start, stop, set breakpoint, 
etc.). This division of debugging computation between the two 
machines is implemented and in use at BBN. A user s manual is 
available (as (BBN]<DOCUMENTATION>XNET.DOC) describing the 

debugger s features and discussing some of the issues involved. 


The purpose of this RFC is to describe our experience with 

response times the debugger exhibits. Response time is a serious 
problem in any elaboration to a debugger. Here we wish to discuss 
the contribution of communicating over the ARPA network to response 
time. The debugger (X-NET) keeps statistics during each debugging 
session, and a debugger command prints them out. We used a 

"Standard scenario" to measure response times on two occasions. The 
first was debugging a PDP-11 at BBN on the same IMP as the PDP-10. 
The second was with a PDP-11 at SRI-ARC in California, with at least 
nine IMPs intervening. 


BBN (local) SRI (distant) 

TENEX LOAD AVG 

START 6.0 4.65 

FINISH 3.9 6.6 

TIME OF DAY 15:30 EST 11:00 EST 
DAY 4/10/75 

4/11/75 
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Each session lasted about 10 minutes. The terms used below 
are: 


message -- a single message generated by the PDP-10 portion of X-NET 


active command -- a command which involves, actually or virtually, 
an interaction with the subject program (e.g., examine, deposit, 
start, stop, set breakpoint, etc.) 


bytes -- the total of all (8-bit) bytes, both sent and received, 
plus any bytes due to receipt of asynchronous replies (e.g., 
breakpoint hit), during processing of the associated message or 
active command. 


wait -- total elapsed time from handing message to implementation 
language (BCPL) network routines, to receipt of the reply from 
these routines and through an inferior process in X-NET 


The 35 active commands in the scenario are: 


1 load program 

8 start or proceed program 

3 halt program 

16 examine contents of memory word 

1 deposit new contents in memory word 

set breakpoint 

remove breakpoint 

word search 

copy program onto disk file 

network/process management (see user’s manual) 


NPRPRPR 


The summary statistics are:. 


BBN (local) SRI (distant) 
AVG STD DEV AVG STD DEV 

PER MESSAGE: 

BYTES 154 295 164 295 

WAIT 1.75 2.04 1.89 0.78 SEC 
PER ACTIVE COMMAND: 

MSGS 0.91 0.69 0.91 0.69 
BYTES 150 331 150 331 

WAIT 1.60 2.36 1.73 1.35 SEC 


The standard deviation is relatively large partly because of a 
small number of samples, but even more because the message size and 
the command complexity are bimodal, as shown by the histograms 
below. The load and word search commands transferred many bytes, as 
did an examine (the first one while the program was halted; 
subsequent examines were answerable from the cache; see user s 
manual). Other commands needed little or no network transaction. 
Those which needed none at all produced a no-delay mode in the 
distribution of waiting time per active command. 
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We conclude that the delay due to network communication is 
tolerable. IE is of the same order of magnitude as that often 
experienced on moderately loaded time sharing systems. More 

explicit measurements of delays seen by user programs in general are 
in progress at BBN and elsewhere; it is beyond the scope of this RFC 
to discuss these delays in detail, or to break down their causes 
into process activation, queueing, IMP performance, etc. Instead, 

we merely note that cross-network debugging is possible ina 
practical sense. 


PER MESSAGE PER ACTIVE COMMAND 


0 š XXXXXXXXX 

16 ; 5 

32 XXXXXXXXXXXXXXXXXXXXXXXXXKXK XXXXXXXXXXXXXXXXXKXX 
64 A XXX 

128 z 

256 XX 3 

5142 XXXX XX 

1024 A XX 

SIZE (BYTES), BBN (local data) = SRI (distant data) Left column 


gives lower bound (inclusive) on logarithmic scale. Thus, two 
messages had at least 256 bytes but less than 512 bytes. An 
examination of network traffic per active command shows that it is 
actually trimodal: some commands are answered from the cache, 
incurring no network traffic; some, such as start or stop, require 
only a few tens of bytes; and some commands, such as word search and 
load, cause transfer of thousands of bytes. 


PER MESSAGE PER ACTIVE COMMAND 
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1/16 X 
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